Vault

{_obsidian_pattern_tag_public}

now working on rdferry

StreamedGraph (lit-element)

<streamed-graph expanded="true">
  <sg-source url="view1.n3"></sg-source>
  <sg-view uri="http://something/in/view1"></sg-view>
  <sg-source url="demo1.n3"></sg-source>
  <sg-source url="/path/to/demo2/graph"></sg-source>
  <sg-source url="/path/to/demo3/graph/events"></sg-source>
</streamed-graph>

This elem can look like nothing (todo), a little summary box, or a big table.

SG contents

The <streamed-graph> elem is backed by a single Graph (read-only) obj that other elems on a page could query or watch for changes.

Each <sg-source> and <sg-view> starts another StreamedGraphClient in the <streamed-graph>, though this client can reduce to a static file loader (as in view1.n3 and demo1.n3 and demo2/graph). You can ask the SGC to reload or periodically-reload the graph.

StreamedGraphClient

The SGC url attribute can fetch these content-types:

content-type reader inside SGClient
application/nquads SingleN3Reader (N3.js has one reader for all these)
application/n-triples SingleN3Reader
application/trig SingleN3Reader
text/n3 SingleN3Reader
text/rdf+n3 SingleN3Reader
text/turtle SingleN3Reader
text/event-stream EventStreamReader

Each SGC's reader emits patches to Graph. Naturally, multiple SGC can provide overlapping quads. Maybe Graph needs quints: (s, p, o, g, source) or (s, p, o, g, refcount). The SG doesn't own any quads; it just queries over all the SGC graphs.

Life of a statement

  1. Something puts a statement into an RDF document or something includes a statement in a source-specific-patch
  2. SGC reports the source-specific-patch (which is possibly the whole document, and also possibly the removal of quads) to SG
  3. SG makes a new SG-patch describing what happened to its graph. The SG-patch has no mention of sources. The SG-patch could be a subset of the incoming ss-patch. SG may choose to throttle its output patches, so the SG-patch might be some aggregate of the incoming patches.
  4. The original statement (maybe, if it hasn't been deleted quickly) appears in an SG output patch that the consumer of <streamed-graph> can subscribe to. Or, if the consumer reloads or queries over the <streamed-graph>'s graph, the statement might appear in there.

APIs

streamed-graph elem:
graph: N3.Store
addEventListener("patch", cb): get patches (which a caller could just use as a ping to reread the graph)
expanded: bool,
status: string, short summary of connection, errors, etc

v2

"> ```mermaid flowchart TB subgraph mg ["MultiStore"] mgdoc("🌈 Primary access to data. Extends Store and is read-only") end subgraph sge ["StreamedGraph element"] sgedoc{{"🌈 primary element"}} end subgraph cs ["ConfiguredSources"] direction TB cs1("Ⓜ️ getStores") cs2("Ⓜ️ getSourceGraphs") cs3("Ⓜ️ getChildSources") end subgraph sgs ["SgSource element"] sgsdoc{{"Children of <streamed-graph>"}} sgs1("🛈 url") end subgraph sg ["SourceGraph"] sgdoc("Brains of <sg-source>. Reads and refreshes RDF data.") sgurl("🛈 url") sgstore("🛈 store") end subgraph s ["N3.Store"] end mg -- "gets data from" --> sge sge -- "provides" --> mg sge -- "contains" --> cs cs -- "refers to (multiple)" --> sgs sgs -- "contains and may recreate" --> sg sgstore --> s cs1 --> s cs2 --> sg cs3 --> sgs ```
Event Fired by Listened by Notes
sourceGraphChanged SourceGraph SgSource not sent on the destruction of a SourceGraph
graphChanged SgSource ConfiguredSources StreamGraph may consolidate change events into fewer events
newSourceGraph SgSource ConfiguredSources a previous SourceGraph may have gone away- this should be in the event
graphChanged MultiStore users possibly consolidated. And how do you know if the graph changed between these evs? Do we need version clocks?

GraphView notes

  1. partition graph into rdfs:label stmts, rdf.type stmts, and the rest
  2. plan what types will make it into tables (2+ instances, primary table type, etc)
  3. fill tables with primary type
  4. do joins and extend tables
  5. group unused stmts by s then p, fill the loose stmt area

Editing structs

It would be nice to use bnodes or something to connect a layout of widgets to a graph structure that can be repeated. The table view is an example of simple paths turning into RO columns, but suppose you wanted to draw the faders in a submaster.

mtail-like for ingestion

Given a file like dhcp_hosts.j2, I'd like to parse the lines and make them visible in lanscape. Then watch the file and when it changes, update the graph plus emit some events.

input text:
# kitchen
1c:f2:9a:63:c3:40,set:filtereddns,10.2.0.242,2h
Output n3:
mac:1cf29a64c430 a dhcp:AssignedHost;
dhcp:tag dhcptag:filtereddns;
dhcp:ip "10.2.0.242";
dhcp:lease "2h"^^:duration;
dhcp:fileComment "kitchen".

others

makepad